I've noticed that every time there is a major update to LR Classic it writes the number of the new update to every image file and xmp. I only noticed this when I go to backup my image files and find that they all need backing up! Of course I could turn off copying to xmp and jpgs etc. I can't see any need for this - recording the new update when an image is edited is fine, but no reason to do it to all of them when not even being looked at.   Bob Frost ... View more

OK, I've just done it again. Created a new catalog, imported the same 50 nefs, and lo and behold it has created 2560, 1280 and 640 previews! That is what you would expect with a 2560 monitor. But when I then created 1:1 previews, it made 8256 and 4128 previews, as expected for 8256 images(?), but altered the existing previews to 2064, 1032, and 320. The previous 2560, 1280 and 640 previews have disappeared! So in this second test, the initial creation of standard previews was in relation to the monitor size, but the second creation (using Build 1:1 previews) changed them all to be in relation to the image size(except for the 320 size).   Make of that what you will! Perhaps all this was best hidden in .lrprev files.   Bob Frost ... View more

Hi Ian, I've read your reply three times, but it does not tally with what LRC 13.5 has actually done in my test. To reiterate, the NEF files imported into my test catalog were fullsize from my Nikon Z8 camera so had dimensions of 8256x5504. They were not cropped either in camera or in LRC (the xmps that they had in my main catalog were left behind). On importing LRC automatically created three new preview files for each image - 2064, 1032, and 320 (according to their filenames). These seem to be correct sizes of 1/4, 1/8, and 1/32 of the actual file size (8256). Why there was no 1/16 is presumably known only by the LRC team. When the 1:1 previews were made these were 4128 and 8256, the 1/2 and fullsize previews. On deletion of 1:1s,  only the fullsize 8256 was deleted leaving the 1/2 size (4128) behind.   What seems to be misleading is the default catalog prefs entry of 'Auto (2560)'. Wondering about that for a while, I suddenly realised that it was the monitor size (Eizo CG 2730) - 2560x1440. The actual previews are not directly related to the monitor size but to the file size (8256).   I hope this clears things up?   Bob Frost ... View more

Not quite finished! To investigate the 1:1 previews in the new preview sytem of LRC 13.5 I created a new catalog and imported 50 nefs (about 45Mp each). LRC created new previews according to its defaults (auto - 2560 and medium quality), and looking at the new previews I have three for each image - 320, 1032, and 2064 in size.I then created 1:1 previews which added 4128 and 8256 in size. Then deleting the 1:1 previews only deleted the largest size that it had created - 8256 - and left the 4128 size that was created by the build 1:1 preview command. Interesting. No .lrprev files at all, but three .lrfprev files for the three faces in those images.   So to sum up, using 'build 1:1 previews' creates two larger sizes of the new format previews, but deleting them only deletes the largest.   Happy Lightrooming!  Bob Frost ... View more

Hi Johan, I don't use publishing services and wouldn't even dream of syncing my images to the cloud! I know, I'm a dinosaur! I don't know whether the copying of previews during and export of the catalog to a new catalog does clean up the previews. I was just reporting what someone else said in another thread.    I used to manually cleanup the catalog using SQlite DB browser until I heard that exporting the catalog did the trick. I have had to do this a few times over the years, usually after an upgrade to a new version catalog. I have not had to do this lately, so LRC must have improved its upgrade process. As to cleaning up previews, I still do that manually. It was usually simple to spot previews that are incomplete or duplicated, and delete them. This current conversion of .lrprev files to separate-size files without an extension has left me with a lot of .lrprev files that I have deleted manually without an effect on LRC behaviour. I suppose I could use my last week's backup of LR to test whether exporting the catalog with previews does cleanup these leftover .lrprev files (assuming they are leftovers!).  Do you know why the .lrfprev files have not been converted? Is it because they only contain one size of people preview already? Coming back to your point about publishing services and syncing, couldn't Adobe sort this out so that exporting a catalog didn't upset them? And couldn't Adobe give us a good repair tool for catalogs? They do repair some catalogs, so they must have one.   Bob Frost ... View more

Deleting the current previews is simple, I agree. But regenerating them if you have a couple of hundred thousand files takes ages, even with the current ability to generate previews in parallel. If you include previews in an export to another catalog surely it just copies the existing previews rather than rebuild them as you suggest?   Bob Frost ... View more

To finish this saga, I deleted all the 1348 leftover .lrprev files on the assumption that they were simply orphaned previews (they all had the same create date of a couple of years ago). I then opened LRC and left it for a couple of hours to update its preview.db file, and then ran 'Build Standard Previews', which said there were none to build. So I was probably right in my assumption, and LRC runs fine. I can't detect any difference in performance with the new preview files, but maybe a hundredth or thousandth of a second is important to programmers!   Bob frost ... View more

In another thread I read that if you use 'Export to another catalog'  with previews (but not images), it leaves behind any rubbish in the catalog, but also in the previews. I've done this in the past to get rid of rubbish in the catalog and improve performance, but I haven't done it with the previews. Worth a try.   Bob frost ... View more

In the past the different size previews of an image were included in one file - the .lrprev file. As I understand, from a different thread, the use of separate size preview files only started in LR 13.5. DavePinPin is using LE 12.5, so the extra files he has should not be separate size previews. Its easy to see - just look in a preview folder. If it has all .lrprev files, there should only be the same number as your images. If it has loads of separate size files with no extension, then each image file should result in several several size files. My LR13.5 has produced six preview files for each image, with -80, or -160, or -320, or -640, or -1280 or -2560 at the end of each name. After converting .lrprev files to the new format files, my LRC left 1349 .lrprev files untouched. I deleted these as I believed they were orphaned previews. After doing this I ran the 'Build Standard Previews' command  and it said there were none missing, and LRC runs fine.   bob frost ... View more

Hi Ian, I think I have answered one or two of my questions! I used 'Build standard previews' on 'All photographs' and that has deleted most .lrprev files and replaced them with the new separate-size files. I have now got nearly 1 million separate-size files instead of 150,000 lprev files. Strange though that there are still 1348 lrprev files left! I wonder why. The .lrfprev files are still there untouched (I think). I suppose the reason for this change is that it is faster to access one of these new files than to unpack the lrprev file to get the correct size preview.   Bob Frost ... View more

Thanks for the reply Ian, but why have some .lrprev files got associated separate size files, some separate size files don't seem to have any .lprev file with them, and some .lrprev files don't have any associated size files. Are .lrprev files redundant, and are being replaced by the separate size files. If so, my LR is presumably part way through replacing the .lrprev files. What triggers their replacement? And what about .lrfprev files? Are they being replaced?   Johan said I don't need to bother about all this, but I like to know what my program is doing when it suddenly increases my preview folder by 400,000 files! It takes longer to backup. And please don't tell me I don't need to back them up. I do, because if something happened and I lost all my previews, it takes an awful long time to regenerate them - I've done it in the distant past when LR was rather flaky at times.   Bob Frost ... View more

Didn't the late RobCole have a plugin that enabled one to step back through history for a batch of files?   Bob Frost ... View more

Thanks Rob, that did the trick. It was the top bar that had disappeared. Must have pressed shift-F by mistake recently.   Bob Frost ... View more

I have always exported my current updated catalog to a new catalog after each major LR upgrade. This seems to leave any rubbish in the old updated catalog behind, and the new exported catalog is then clean. Go to 'File/Export as Catalog', give the new catalog a new name, and only tick the bottom checkbox to 'include available previews'. It is fairly quick;the only disadvantage is the it creates a new prefs file (which you will need to edit). Not sure what happens to plugins, since I don't use more than one or two occasionally.   I just did this today and the new exported catalog runs with amazing speed, compared to the old updated catalog. I once looked at what happens when you do this, using SQLite browser, and could see the faulty stuff left behind by the export. I've done this for years now, and sometimes inbetween major upgrades if I think there is a slowdown.   Definitely worth a try.   Bob Frost ... View more

Sameer, How does this method differ in result from the way I do this - Export to a new catalog.   Bob Frost ... View more

Big desktop   Bob Frost ... View more

So if some of the details in the Prefs file are 'hidden' to view with a text utility like Notepad, what do we need to see all the details? Just curious! Bob F     ... View more

Most LR users do not know that this list exists. I used to be our local computer 'expert' at our camera club, and having read this and other lists for many years, deleting the prefs file was often used to solve LR problems. I have a selection of my prefs files with 'old', 'bad', 'good', 'new' attached to the filename, and I can always get an older prefs file from my system backups with Macrium backup. But I thought saving the Prefs file in LR backup might make life a bit easier.   If the error in the Prefs file is not visible, why does starting with a new prefs file solve the error? Are you saying that some errors in the Prefs file are not listed in it, are hidden?   Bob Frost   ... View more

Hi Ian et al, Timed my backup of my 4GB catalog with integrity check and optimization checked. The result was 15 secs for integrity chec, 60secs for copying catalog, 30 secs for optimization, and 30 secs for compression. All with the graphics card OFF. Then I thought I better time it with the graphics card on Auto, and  it worked perfectly with the same times as with it OFF. Repeated this several times and each time it worked perfectly! So yesterdays problem must have been just a 'gremlin in the works' - a hit from a cosmic ray? Very strange!!!!!   Bob Frost ... View more

Before anyone asks, I am using latest LRClassic 12.1 and  latest Win10 ... View more

If you have write to xmp auto AND to jpgs/psds/etc, LR 11 will write to all of them just to record the fact that it is installed!!! Quite ridiculous. but just leave LR running overnight and it will update everything by morning. Hopefully.   Bob Frost ... View more

My experience with LR since version 1 many years ago, is that the fewer things that you ask LR to do at the same time the more likely it is to do them correctly. So I don't do all the extra things you list as theoretically possible on import, I just want LR to add my files on my hard disk to its catalog. That is simple using Synchronise and LR should cope with that without too many errors. Then once they are in the catalog, I may rename them, etc, etc, one thing at a time. Copying my images to my hard disk is simple for my file manager; it doesn't make mistakes. Synchronising that folder into LR is also simple, and works well IME. That gives me an unedited image file in LR's history. Editing comes later. Trying to do everything on LR's import is a recipe for disaster IME; it often can't even get the correct folder to import into!   But if you like a risky existence, by all means try all your suggested editing on import. It will probably keep this forum busy!!   PS I'm  probably not contributing to your forums any more, since I object to not only having to enter my email and password, but now I have to get out my phone and enter a number you send me!! It's simply not worth the hassle just to comment on a post!!   ... View more

"Stop using 'Sync Folder'- It is not the ideal way of importing your images to LrC. Use the better 'Import' dialog."   Hi Rob, I gave up using LR's Import years ago because it was so flaky. It is better now, but still gets the import folder wrong sometimes. I have even had to edit the catalog to cure this problem. So I copy images to a folder using my file manager and then synchronise in LR. Why do you say this is not ideal?   Bob Frost ... View more